Iaasvmsshpmagentssh

ssh:

agent
:



sshweb server agent

this thing has been done before, there has been reflection, and even the design of the prototype is exactly the same as you said.

for example, why do I use web server-based agent? why don't I use tcp to connect to the server so that the result of execution can be streamed to the caller, where it is smoother and does not have to wait for the result of each command execution.
but if I do this, the central control end traffic and log storage will become a problem.
if all my business is on the cloud, and if the networks of different computer rooms are not interconnected, I will have to do something compatible with each other.
for example, agent's life cycle, why should I test her heartbeat? If there are tens of thousands of machines, anything possible will happen, ah, it is too painful to repair. But if I don't deal with it. So I will consider using ssh to repair agent later.

I assume that all your machines are linux, distributions of the same type.

SSH:

1. depends on the speed of ssh, and once the network jitters, the ssh operation will fail. (low probability / risk)
2. depends on key, if your security policy is not strict enough, or if your management is not strict, then it will inevitably lead to a flood of root key. (high security risk)
3. Open source technology is so mature that you can easily wrap a complete script in a few lines of python, or write an ansible configuration. (easy to use)

AGENT:

1. depends on the central control. If you're not going to have a central console, it's no different from ssh.
2. in fact, like SSH, it depends on the network, and there will be problems once jitter occurs.
3. keep alive. If your company is a little bigger, there will be a variety of reasons why your agent won't work, or even be kill. Although there is no problem with dealing with it, someone has to do the job. (low risk)
4. maintenance. (medium cost)
5. agent can actually not use intermediate code, because on the one hand, the workload is relatively large, on the other hand, the cost of education and learning is also relatively high. Just send shell script to agent, python script and so on can also complete the same function, no problem.

large companies have all kinds of audit and security requirements, and they will unify this kind of things to a certain place and set up a central control terminal, and all batch operations must go through the central control terminal. The mode is also different. Some use agent, and some use ssh,. Only the central control side is necessary.

to put it bluntly,
you are a small company, and if you have less than 30 machines or less than 50 machines, it is not recommended to consider agent mode.
there is no such demand, the cost of input is high but the efficiency is low.
just wrap one based on a variety of third-party frameworks, and use ansible if you find it troublesome.

• it's easiest to use ssh if you manage OS of the same kind, such as Linux,.
• if there are other OS, then SSH may not work, and agent can shield the difference between OS to some extent. For example, in a solution such as puppet, the actual operation instruction issued is not an instruction actually executed on the machine, but a intermediate code , which is translated by agent into the local command that the current OS should actually execute.