combine all binaries into one

[siddontang]

Feature Request

Is your feature request related to a problem? Please describe:

Now we have three binaries: tikv-server, tikv-ctl and tikv-importer. Compiling them all may take a long time, and another problem is that people may misuse different versions, e.g. one people used an old tikv-ctl to access tikv-server.

Describe the feature you'd like:

We may combine all into one binary, I guess this can also improve the compiling time. /cc @brson

So now there is only one binary, assume the name is tikv, so the commands look:

tikv server xxx
tikv ctl xxx
tikv importer xxx

To support compatibility, we may provide a tikv-server, tikv-ctl, tikv-importer script, like:

# tikv-server
tikv server $@

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Some documents should be changed:

• The binary deployment
• Docker
• tikv-ctl
• Lighting

The ansible and K8s operator should also be changed.

[BusyJay]

I don't think this will improve compile time. When building three binaries, they are compiled in parallel. And tikv-server is always the last one that finish compilation.

The overall idea looks good to me.

[Hoverbear]

This is a super great idea!

[Hoverbear]

We should consider that if we do this with TiKV the same should be done for PD to maintain consistency.

[brson]

I think probably it makes sense.

If there were a way to run a post-install script, we could even preserve the existing names by linking e.g. tikv-server, tikv-ctl etc all to the same binary. But just making them all one binary and changing the command format is also fine. Similarly for backwards compat, sym/hardlinks could link tikv-server etc to the new tikv command.

For less parallel builds it will improve build times. It will make tikv-ctl only builds impossible - so that it takes just as long to build that feature as tikv-server, which is probably fine. It will reduce memory consumption during parallel builds by only running LTO and the linker once.

I can't think of a great downside, except that it could be argued to violate the single responsibility principle.

Doing this would decrease the distribution size.

It could be worth considering something similar for the benchmarks - I noted it takes me 95 minutes to build all the benchmarks with thinLTO. Though that would make it take longer to build individual benchmarks.

[kennytm]

Note that we've split tikv-importer into its own repository (https://github.com/tikv/importer) and the copy here will soon be deleted on master.

[gregwebs]

It is very easy to try this idea out by putting all the binaries into a single docker container. Create a dispatch shell script called tikv if you want. See jaeger all in one for inspiration. Note this can also be done just by putting all binaries into a single directory.

Note that with this approach it is also easy to add in PD, whereas this issue does mention PD, presumably because combining go and Rust into a single binary is harder.

[tennix]

As for compatibility, the hyperkube approach is a good solution. The hyperkube is a binary wrapper for all the k8s binaries, when running hyperkube --make-symlinks, it will create all the symbolic links to hyperkube, and invoking hyperkube <component> is equivalent to <component>, for example to run kubectl, users can also run hyperkube kubectl.

To try and play yourself, you can use the following command to enter the hyperkube docker image:

docker run -it --rm --entrypoint=bash k8s.gcr.io/hyperkube-amd64:v1.12.2
# ls -l
total 242276
lrwxrwxrwx   1 root root        10 Oct 24  2018 aggregator -> /hyperkube
lrwxrwxrwx   1 root root        10 Oct 24  2018 apiserver -> /hyperkube
drwxr-xr-x   1 root root      4096 Sep 18  2018 bin
drwxr-xr-x   2 root root      4096 Jun 26  2018 boot
lrwxrwxrwx   1 root root        10 Oct 24  2018 controller-manager -> /hyperkube
drwxr-xr-x   5 root root       360 Jun 17 23:07 dev
drwxr-xr-x   1 root root      4096 Jun 17 23:07 etc
drwxr-xr-x   2 root root      4096 Jun 26  2018 home
-rwxr-xr-x   1 root root 248021112 Oct 24  2018 hyperkube
lrwxrwxrwx   1 root root        10 Oct 24  2018 kubectl -> /hyperkube
lrwxrwxrwx   1 root root        10 Oct 24  2018 kubelet -> /hyperkube
drwxr-xr-x   1 root root      4096 Sep 18  2018 lib
drwxr-xr-x   2 root root      4096 Jul 16  2018 lib64
drwxr-xr-x   2 root root      4096 Jul 16  2018 media
drwxr-xr-x   2 root root      4096 Jul 16  2018 mnt
drwxr-xr-x   1 root root      4096 Sep 18  2018 opt
dr-xr-xr-x 763 root root         0 Jun 17 23:07 proc
lrwxrwxrwx   1 root root        10 Oct 24  2018 proxy -> /hyperkube
drwx------   2 root root      4096 Aug 10  2018 root
drwxr-xr-x   1 root root      4096 Sep 18  2018 run
drwxr-xr-x   1 root root      4096 Sep 18  2018 sbin
lrwxrwxrwx   1 root root        10 Oct 24  2018 scheduler -> /hyperkube
drwxr-xr-x   2 root root      4096 Jul 16  2018 srv
dr-xr-xr-x  13 root root         0 May  7 06:58 sys
drwxrwxrwt   1 root root      4096 Sep 18  2018 tmp
drwxr-xr-x   1 root root      4096 Jul 16  2018 usr
drwxr-xr-x   1 root root      4096 Jul 16  2018 var
# /hyperkube kubectl version
Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-24T06:43:59Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
The connection to the server localhost:8080 was refused - did you specify the right host or port?