Development process with Docker

One answer at a time:

  

Technically Docker generates "machine snapshot" so all developers will pull the same hub to have no difference in the correct container?

Exactly. This machine snapshot that is called container . This container has all the necessary environment to run your service.

  

Is this container on the machine of all team developers or on an external server?

This varies greatly in the workflow of each team. The container is usually the end product of the development process, in the sense that it has the ability to run the service with just one command, and it is also going to production.

  

I coded on my machine and "deploy" the container only after development?

Yes, what you are looking for is Automated Builds , which is a Dockerhub feature that allows you to align a Github repository with a container, Dockerhub will try to make a docker build , with Dockerfile present in the root of the repository.

  

Does the approval environment continue to be used after Docker?

One of the advantages of Docker is to be able to run the homologation environment on your machine, or to easily recover it in case something goes wrong. However this does not exclude the need to have an approval environment, it is always important to test and validate the services and if the containers are running accordingly.

Your question is clearly not from Docker, but from Devops . It also includes Docker and other concepts, which make use of Docker, such as Continuous Integration and Continuous Delivery.

Devops has enabled an automated and agile delivery process. I recommend taking a look at this concept, as it encompasses the use of Docker in production. Some interesting links:

• Whitepaper Docker and The Three Ways of DevOps
• DevOps Wiki

Based on my experience with Docker:

• Whether or not to use Docker in the Development process depends on the established process. For example, in my process I have a base_container containing all the dependencies of a Project (like ruby + sinatra). From here I have 2 processes, one like my dev environment and one of builds (for Homologation or Production). In the dev environment I use the base_container and I mount the volumes with project code. In the process of build CI use to generate the final containers and from them game in Production.

• Containers are usually stored on servers: Docker Registry for Internal Server or DockerHub contracted as a service.

• Yes, ideally do in different processes .. as in response example 1. Generally a Dev container is polluted with manual installations, test files, randomly modified configuration files, etc. But nothing prevents it from generating tags from a developer machine, it depends on the established process.

• The Homologation environment is important if you need to consolidate the delivery of various projects, codes, containers .. or when you have a large team of developers and need to group all the changes before taking them to a production environment. Particularly I would start observing Continuous Delivery and BlueGreen Deployment so that it is possible to shorten the time between commits and deploys in production.

I hope I have helped.

Well, taking as an example the process I've been using:

Generally, custom images (from Dockerfiles ) are generated to meet the needs of each application service, such as web services, database server and caching server. From these images, each image generating its own container. And the use of docker-composer for orchestration of all services, facilitating the set-up of the whole environment.

For practical purposes, in a development environment, we mirror the application source code through Volumes of Docker into their respective containers, so each developer runs < in> build of images and runs your container, locally, with your version of the project. So theoretically you develop on your machine, but with results being reflected in real time in your container.

Already for the QA environment, production and the like, you can use an image repository (such as DockerHub , or a private DockerRegistry ) where no more we mirror the source code in the container, but we just embed it inside it. The deploy process from there basically becomes a pull , on your server, of the corresponding image.

The great benefit of Docker is the ease of reproducing the same conditions of the production environment on any other machine, but this does not exclude the need for approval environments and this goes through the development process of each project. >