Development practice case sharing based on Docker

At the moment, the container has become a very popular trend, and when it comes to containers, people usually talk about Docker. Even the container has its own verb form containerizing to describe the use of Docker to package the application.

After a heated debate, the focus of the Docker has migrated to how to use containers in a real-world production environment, and people have applied the philosophy of "containerization" to storage, networking, or management.

There is no doubt that under this strong momentum, Docker can be used stably in the production environment is certainly not too far. This will share some of the Docker-based use cases that have been validated by engineers.

First of all, in another blog I have briefly mentioned these, and this article is based on the extension of communication with colleagues. These are not, of course, a rebuttal to Docker just a market trend statement.

Here, I do not want to continue to explain functional testing and different types of software testing. There are already many articles explaining why unit testing must be based on real service and running environments.

Now, test-driven development based on unit testing has proven to be a good way to develop applications, and the entire development process will be inseparable from unit testing. Typically, you start writing unit tests and code at the same time, and iterating through the Code and unit tests in an iterative fashion.

When the code is working properly, it is typically submitted to a CI environment to run unit tests before review and merge, perhaps with some functional testing before review and merge.

Functional tests for a feature are not submitted at the same time, because functional testing is not easy to do and can take a lot of time. You have to configure everything correctly, such as the initial establishment of the database, such as how to communicate in the context required for testing.

At the same time, even if you build a test environment in this way, and it works well, most people still simply place it in a virtual machine shared by several colleagues instead of setting up a whole set of environments that interact like DB, app, and Web server. You're certainly not going to test application extensibility because it's more expensive.

And these, you use Docker and fig collocation can be easily achieved. You can specify different environments and quickly deploy them. You can run different goals and content directly in CI, and more importantly, you can easily share it with your colleagues. It's all because of Docker, which can build some very smart caches for mirroring and run them in seconds.

When building dockerfile, you specify how the application is built and what configuration is specific. Again, you can show the user how it works. Given that you don't have the experience and skills of a professional complex software deployment practitioner, the results may not be perfect, but at the very least, you can tell the user how the work is done, rather than letting them rack their brains.

In another blog, I introduced dox. If you've ever played OpenStack, you'll find that OpenStack often need to run many very complex tests, so we need a system to simplify the complexity of the process. However, not only OpenStack have these very complex tests, such as you need to run SQLAlchemy, and you need sqlite at the back end to run your unit tests. But eventually you may end up with some very strange states, such as the foreign keys not working properly, and some other SQL features are not implemented. But with the container, you can easily pack up the configured DB to complete these tests easily. And so on, when you need to rely on a system, or some configuration/file, Docker can easily package them.

Hopefully, after understanding these points, you can be more determined that the container is an essential part of the development process. At the same time, I hope that more content will be added to these workflows, and there will be more powerful tools in the future to make development more convenient.

Original link: Use cases for Docker driven development. (Compilation/Dongyang revisers/Zhou Xiaolu)