The base images are meant for development, and include everything needed
to bootstrap and build Vitess.
For actual deployment, we can drop all the dev packages and just put the
binaries into a fresh image.
At this time, the savings in image size are:
vitess/base = 2.269GB -> vitess/lite = 568.4MB
vitess/etcd:v0.4.6 = 442.4MB -> vitess/etcd:v0.4.6-lite = 108.6MB
This makes Kubernetes pods start a lot faster, since each node has to
download the images.
Otherwise, you may get permission denied when trying to remove the temp
dir as a normal user, because the files were created by the 'vitess'
user inside Docker.
This is an alternative to 'make integration_test',
with the following advantages:
* Tests run in Docker, so no bootstrap is necessary.
* Tests are hermetic and can run in parallel.
* Test against different flavors just by setting a flag.
* Failing tests are retried to see if they are flaky.
* A failed test will be recorded for later inspection, while the script
continues to run other tests.
* A test that takes too long will be considered stuck and retried.
There's plenty of room for improvement, but now that we have something
in a more readable language than Makefile, we can iterate.
This will let contributors test changes without having to do bootstrap
at all.
It also makes it easy to test against multiple flavors without having to
swap out installed packages. You can even run tests against multiple
flavors simultaneously without interfering, if you have enough RAM.
This makes it faster to use Docker images to test new changes, as
suggested in #492.
Since we don't need to re-bootstrap for every push to master, this also
makes our automated builds faster and more reliable (they often fail due
to network lag when installing dependencies with apt-get).
Lastly, this will make it easier to swap out bootstrap images built for
different flavors, such as MariaDB 10.0 vs MySQL 5.6.
The useful parts of the zk Docker example have been absorbed into the
Kubernetes example. The Docker-only version is now broken anyway and
there's no point in fixing it since we're not planning to flesh out the
rest of Vitess in Docker-only mode.
Anthony Yeh