make: build vitess as static binaries by default

[vmg]

Description

We're trying to solve two related issues here:

1. Since the introduction of vtorc, all the different binaries have ballooned up in size and dependencies, because the CGo dependencies of orchestrator (namely, SQLite) were being propagated through the build.
2. Since newer versions of Go have been released, dynamically linked Go binaries depend on newer versions of libc that are not available on older OSSes.

Let's try to fix the two issues at once: first, we stop importing the go-sqlite package on orchestrator's sqlutils package, because it's being used in other parts of the codebase. We can add the dependency at the root of the binary itself. Secondly, we update our Makefile so that CGo is disabled by default for all binaries except vtorc.

Building Vitess with CGo disabled by default has a major implication: vitess will use Go's native DNS resolver always, and this could potentially be a breaking change. Usually, the Go runtime chooses the DNS resolver dynamically at runtime, between its native resolver and the one on glibc based on some heuristics. The native resolver is always selected unless the runtime detects configuration options in resolv.conf or /etc/gai.conf that it doesn't know how to handle (you can see the full heuristics here). By disabling CGo, the native resolver will always be used, and particular deployments that customize their DNS resolution in unsupported ways will error out with a helpful message.

How breaking is this change? I'm not sure, that's why I left a target in the Makefile to keep building versions of Vitess that depend dynamically on libc. I think that the sensible choice by far would be to ship Vitess as static binaries by default, because it greatly simplifies deployment in a large amount of (older) OS versions that we couldn't support otherwise -- an use case much more frequent than deploying in modern OSses with env-defined local resolver configurations.

Related Issue(s)

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build/CI
• VTAdmin

[shlomi-noach]

👍 to the change in sqlutils

testing the Makefile changes at your discretion

[deepthi]

Building Vitess with CGo disabled by default has a major implication: vitess will use Go's native DNS resolver always, and this could potentially be a breaking change.

We have gone back and forth with CGo. Vitess used to have a CGo dependency that was removed around 2018, and it was added back when we brought in orchestrator in 2020. I don't believe this will be a big deal. Nobody reported issues during either transition.

[vmg]

@deepthi: Good to know. I've switched to static build by default then; all tests are green. Good to merge?

[deepthi]

Let's have either @sougou or @dkhenry review as well. Once we get an OK from one of them, it will be good to merge.

[dkhenry]

I agree with @deepthi when we made this change last time we didn't see any impact. It would still be good form to list this in the v10 release notes as a potential breaking change.

[deepthi]

I agree with @deepthi when we made this change last time we didn't see any impact. It would still be good form to list this in the v10 release notes as a potential breaking change.

@askdba please make a note for release notes (assuming we are porting this to the release-10.0 branch).

[deepthi]

@vmg can you create a cherry-pick PR on the release-10.0 branch so that we can get this into v10?

[vmg]

👍 I'll do it first thing tomorrow.

[vmg]

Here: #7808