We reduced the deployment time for multiple environments by a factor of 10 using Docker deployment, and also saved 2 operations and maintenance positions for a team of 10 people.

Last month, our small SaaS e-commerce team in Singapore almost failed. We were updating the inventory synchronization feature for three Southeast Asian sites just before a major promotional campaign. The tests on our local servers went smoothly, but once we deployed the new code to the cloud servers in Indonesia, we encountered a problem with missing dependencies. It took two backend developers and one operations engineer 18 hours to fix the issue, which delayed our planned stress tests by three days.

First, understand what Docker deployment actually is.

In simple terms, it means packaging all your application code, dependent libraries, configuration files, and even operating system kernel parameters into a standard “container image.” No matter how your application runs locally, it will perform the same way whenever you deploy it to any server that has the Docker engine installed.The minimum size of a single image can be reduced to 20MB, with a startup time of no more than 1 second.。

We used the actual earnings from the past 3 months.

First and foremost, the issue of inconsistent environments has been completely resolved. Previously, it would take half a day just to assign different versions of Node.js and database drivers to each site. Now, the packaged images can be directly uploaded to the image repository, and all three sites can be deployed with a single click. The deployment time has been reduced from an average of 4 hours to 24 minutes. There's no need to stay up all night anymore for version updates before major promotions.

Secondly, the utilization rate of server resources has doubled. Previously, we rented a 2-core cloud server (4G) for each site separately, and the CPU utilization was less than 10% when not in use. Now, by using Docker to consolidate the applications, caches, and scheduled tasks from all three sites onto a 4-core server (8G), the resources are used efficiently.The monthly server cost has been directly reduced by $620.For a small team of less than 10 people, that's not a small amount.

Finally, the capacity expansion speed can keep up with sudden traffic spikes perfectly. Last year during Black Friday, it took us almost 2 hours to set up additional servers. This year, 10 minutes before the peak period, we launched 12 container replicas, which were able to handle three times the usual traffic volume, and there were no request timeouts again.

Don't rush to get in the car; we've already avoided those pitfalls for you.

The first issue was that the images were too large and bulky. Initially, we used the official Node.js full-featured image for packaging, and a single application image weighed up to 1.2G, taking over 20 minutes to transfer to the overseas image repository. Later, we switched to an Alpine-based image, removing all unnecessary dependencies, and the final image size was reduced to only 90MB, which significantly increased the transfer speed by more than 10 times.

The second issue was that the data was stored inside a container. At first, we didn't notice this, and we stored the product images uploaded by users directly in the local directory of the container. Later, when the container restarted, all the images were lost, and it took us a whole day to recover them from the backup. Since then, all the persistent data has been mounted to the local directory of the server or object storage, and no further problems have occurred.

The third issue is the lack of resource restrictions. When the system was first launched, no upper limits were set for the CPU and memory usage of the containers. Once, a bug in a scheduled task on one of the sites caused it to consume all the server's CPU resources, resulting in the failure of the other two sites as well. Later, resource limits were established for each container, so that even if a single service encounters a problem, it will not affect the overall system performance.

Should we use Docker or not? Our criteria for making this decision are very simple.

Use cases: You need to deploy the same application on multiple servers, frequently switch between development/test和生产 environments, and your team has more than 3 members, each with a different development environment. Using Docker will only improve efficiency.

Situations where Docker should not be used: If you only have a small blog, run it on a single server, and update the code only once every six months, there's absolutely no need to spend time learning Docker. Using Baota or manual deployment would be much more convenient.

3 specific suggestions for beginners

• The first 3 times you package an image, directly search for the best practice templates provided by the official sources. Don’t create your own Dockerfile from scratch; this can help you avoid 80% of the issues related to image bloat and permission errors.
• At the beginning, there's no need to use complex orchestration tools like K8s; managing up to 3 services with Docker Compose is more than sufficient.
• Use the overseas nodes provided by cloud service providers for your image repository; don’t set it up yourself. The time you save can be used to develop several more features.

Common small issues and their unified answers

Question: Will Docker consume a significant amount of additional server performance? From our tests, the performance loss is less than 5%, which is completely imperceptible for the vast majority of small and medium-sized teams.

Question: Can the old applications be migrated to Docker? Of course they can. We have a PHP project that has been in use for 3 years, and it only took us 2 days to create the Docker image and complete the migration. It was much faster than setting up the environment from scratch.