Per-push docker tags

[Totktonada]

Like it is done in https://github.com/progaudi/tarantool-docker

[aensidhe]

I've actually fixed the build, but you can grab anything you find useful in my repo and I'll deprecate it to remove separation

[Totktonada]

NB: I guess it worth to keep :latest, :1, :2, :x.y being updated on per-release basis (because users likely expect that they will be updated this way), but push docker tags per-tarantool-push. We can also add :1-live, :2-live, :x.y-live for last pushed version in the corresponding tarantool branch.

[Totktonada]

I've actually fixed the build, but you can grab anything you find useful in my repo and I'll deprecate it to remove separation

BTW, can you share what else is worth to be updated from our side? As I see, you at least add some modules.

[aensidhe]

BTW, can you share what else is worth to be updated from our side? As I see, you at least add some modules.

I've added spacer and luautf8 only. I believe now you need only former, latter (it's analogue) is integrated into tarantool

[aensidhe]

NB: I guess it worth to keep :latest, :1, :2, :x.y being updated on per-release basis (because users likely expect that they will be updated this way), but push docker tags per-tarantool-push. We can also add :1-live, :2-live, :x.y-live for last pushed version in the corresponding tarantool branch.

Or you could have :1-release :)

[Totktonada]

We shortly discussed it with @oleg-piskunov and @avtikhon and now I feel a need to clarify this issue a bit. It is filed to bring the question into attention and to start the discussion.

There are different ways how we can proceed with it if we'll decide to do:

• We can implement it partially: only fully qualified tags or only 'live' rolling versions.
• We can keep current 'release' rolling versions and name 'live' rolling versions differently or stick with one of approaches.
• We can choose a naming scheme (say, 2-live, 2.4-live or live-2, live-2.4) or even decide to deploy live and/or fully qualified images into a separate docker hub repository.
• We can even decide to keep the current processes for our docker repository and leave progaudi repository to be the separate service / repository. Maybe just mention it is our download instructions on the website.

So, again, it is for discussion, not "I am absolutely sure we should implement everything what I proposed".

Now, why I ever bother with it? There are several usage scenarious, where fully qualified or live docker images may be useful (as well as RPM / Deb packages). I see the following:

• Bisect of a problem of an application / of tarantool using pre-built docker images.
• Have fully qualified dependency on tarantool in an application / a service, which is deployed using docker (or have such deploy variant) to ensure that nothing will be surprisingly changed.
• Verify a module or a connector in CI using a latest version of tarantool within a series (like 2.4) to catch problems before a release.

[knazarov]

If you want to make Tarantool Docker containers better, here are a few things I'd do:

• Don't ship any modules by default. They get old, and previous versions of docker containers don't get new modules. This may confuse users who want to base their app on fixed versions of Tarantool. And they may get modules with bugs that have already been fixed.
• In fact, only ship Tarantool itself in the container
• Make it easy to install modules. Currently in our container you have to install git, cmake and other stuff to install modules through tarantoolctl
• So, add the necessary stuff to install modules (gcc, make, cmake, git, curl, etc...)
• Move to "stackbrew" to automatically build newer versions of containers
• Move tarantool from tarantool/tarantool to just tarantool, making it an "official" image on docker hub (using stackbrew will help here, as the official containers can only be built with stackbrew)
• By using stackbrew you'll automatically achieve the "auto-bump" functionality you want here
• Move away from alpine, to a more mainstream distro (official images are suggested to use debian)

If you want an example of how we can use stackbrew with Tarantool, you can take a look at what I did with the experimental "tarantool-cartridge" container here: https://github.com/tarantool/cartridge-docker