In the previous article, we discussed the hardware selection for building a home data center. In this article, we will mainly discuss the selection of software environment.
Contents
Deployment method selection
Currently, there are two mainstream ways to deploy applications: LNMP (LAMP) or docker.
1. Use LNMP (LAMP)
This is what we usually call source code deployment, which is suitable for direct deployment on a bare server. This method does not cause any performance loss to the server, and it is also convenient for applications to call and visit each other. The disadvantage is that the early deployment preparation work is complicated, requires various compilations, and is very inconvenient for later migration.
2. Docker
This method greatly increases deployment flexibility and portability, and can be used in conjunction with container cluster management systems such as k8s to achieve automated deployment, automatic scaling, and maintenance of container clusters. The disadvantage is that there is a small loss in performance.
In terms of application deployment methods for home data centers, the Docker method has obvious advantages over the LN(A)MP method, so we will mainly use the Docker method when deploying home data center applications in the future (there are exceptions, which we will mention later, such as load balancing deployment, which is not suitable for the Docker method).
Virtual Technology
As for the choice of virtual technology, I will use a combination of virtual machines and LXC. LXC is the most recommended method under normal circumstances. After all, it not only realizes application isolation, but also does not have the performance consumption brought by simulating the underlying hardware like virtual machines, which just meets my needs (on the other hand, the disadvantage of the LXC method is that the isolation is not thorough, whether it is the application level or the hardware resource level. For a real enterprise production environment, saving that little bit of hardware consumption is actually not very meaningful, after all, hardware is now extremely cheap, so it can only be said to be suitable for the needs of home data centers), and virtual machines (Linux) are used to provide some special applications that require complete resource isolation (we will talk about this later), and I also need a 24-hour online Windows system as a remote operation and maintenance device (Win's RDP is indeed the best experience among all remote access, VNC is really hard to describe... Of course, Mac-mini can also be used, and the remote experience of using Jump Desktop with Mac-mini is also good. Win is considered when there is no terminal with you, you can find a machine in an Internet cafe and use remote desktop to connect), so I finally chose PVE as the virtual platform.
Why not choose Esxi as a virtual platform? First, it is a paid software. One of the principles of building a home data center is to make it free, so this is definitely not an option. Second, Esxi is not playable. PVE itself is a Debian 11, which can be installed with various software and has high playability. Third, PVE directly supports LXC. Fourth, PVE provides cluster and backup functions for free. . .
Actual environment display
Let me show you my current actual environment:
1. Main container operating environment, mac-mini:
The stopped elasticsearch is used for full-text search on nextcloud. I disabled it because it consumes too much memory and plan to migrate it to a backup platform later.
2. Backup container operating environment:
3. PVE virtual machine:
bt-only is an LXC that I use to run a pagoda panel. This LXC carries the reverse proxy work of the three entrances of the home data center, and is responsible for forwarding the requests coming from the three WAN ports to the background WAF. The background WAF uses the community version of Changting Leichi (free and easy to use), which is responsible for filtering the requests and forwarding them to the background load balancing device. The load balancing uses the community version of zevenet (free and easy to use), which is responsible for forwarding the requests to the appropriate docker. The above is the process of request forwarding within the home data center.
