Before introducing the deployment mode of tarsdocker, this paper first introduces several typical deployment modes of tarsdocker, each with advantages and disadvantages, which can be selected according to the actual situation
Tars deployment Basics, Tars consists of MySQL + framework services + business services:
After tars is deployed, from a server perspective, it consists of the following parts:
The deployment of tars includes:
Note: if the business services implemented in different languages may be running on the node server, the running environment of the node server usually needs to be installed by itself, such as JDK, node, etc
There are several ways to deploy tars:
Source deployment is a very good way to understand tars. For details of source deployment, see here, Reading is highly recommended.
The main steps are as follows:
Source compilation deployment please see Install, recommend to read.
Tars framework services run on the server in independent process mode, which can be started and stopped manually, and each service can be updated independently
Note: this method is recommended for teams familiar with tars
Although the source code deployment can be updated independently, it also brings inconvenience. After all, the update of each module is more troublesome. At the same time, the module version may still depend on it, and the update maintenance is more troublesome.
In this case, you can choose the framework docker deployment: in short, you can container the framework service and the web. When you start the container, the framework service will start automatically and update as a whole
There are three modes of docker making in the tars framework:
The differences between the source code make and auto make:
Make docker through source code >- You need to download the source code manually and make docker step by step >- The mirror used china mirror, which is easy to be made successfully >- The created image does not contain the business services of the runtime environment, such as Java, PHP, etc., and cannot be published to the internal of the docker image
Auto make docker >- Auto download source code, make, make install and make docker >- The default source of the system used may be connected to overseas sources, which is slower (but the action is faster when it is created on GitHub)
Although the deployment of docker framework greatly facilitates the deployment of the framework, there is still a lot of work to be done for the team using k8s to manage containers.
Therefore, here, a way to deploy tars on k8s is provided:
Please See here
Note: the internal docker provides the running environment of various languages. Simply speaking, the business service can be published to the internal docker for running (equivalent to treating the docker as a virtual machine)
Although this method does not make every service a pod and run on k8s independently, it also basically solves the problem of combining tar with k8s. Although it is not elegant, it can be used as a way integrated with k8s.
The core problem that needs to be solved in this mode is that both framework services and tarsnode, as pods, may die and drift, resulting in IP changes. How to solve this problem:
In the above k8s docker deployment, although tars is deployed on k8s to run, k8s is not used for actual release and capacity expansion, but k8s is regarded as a container management platform
The deep integration of tars and k8s is still in planning and development