Refactor docker structure [docker]

[OnkelTem]

Well, let me share my thoughts about how the whole thing can be updated.

• Move docker stuff into a separate directory and refine overall structure
• Push docker bootstrap scripts inside docker images
  • Split scripts/docker-startup.sh
• Make it possible to configure user id from inside docker-compose.yml
• Create regular volume for database so that container termination wouldn't kill (precious!) data.
• Add missing fonts for mapnik into kosmtik image
• Update docker-compose.yml version format to '3.2'.

I'm creating a branch in my fork with those changes.

[OnkelTem]

Ready to send a PR. But may I send it into master or you'd create a separate branch for it?

[OnkelTem]

You can get the idea of the new structure here:
https://github.com/OnkelTem/openstreetmap-carto/tree/refactor-docker

[matthijsmelissen]

Sending to master is fine.

[kocio-pl]

Update docker-compose.yml version format to '3.2'.

Why is this needed? My docker-compose 1.8.0 (Ubuntu Xenial backport probably) was not able to start building.

[OnkelTem]

@kocio-pl

Why is this needed? My docker-compose 1.8.0 (Ubuntu Xenial backport probably) was not able to start building.

There is no specific reason I can name right now, but docker and docker-compose are still under active development, and using their old versions doesn't seem to be a good idea anyway, so just update them.

Update docker-compose (up to v1.17.0)

https://docs.docker.com/compose/install/#install-compose

or simply:

sudo curl -L https://github.com/docker/compose/releases/download/1.17.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

Update docker (up to v17.09.0)

https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/

[kocio-pl]

I know how to do it, but that's not the point (though I have a private policy to use only packages and avoid /usr/local/* mess). I changed version to "2" and it worked, so it looks like you are bumping version just in case, which makes no sense for me, because it's probably not necessary, so it alienates users for no apparent reason. It means that if somebody can't update docker/docker-update (there might me different cases we don't know), he can't use this.

I think it's better to not add artificial obstacles to not make life harder than it already is (installing Docker might be hard enough for some people).

[OnkelTem]

@kocio-pl As in your case people may use some outdated versions and you may get some unpredictable results so it's better to force them to update, especially if you use some relatively new software like docker. By using the same updated software (or at least of close versions) you narrow down possible issues. Writing dockerfiles or docker-compose files for "2" is like using openstreetmap-carto v.2.4.0. Lots of bugs have been fixed since then.

[kocio-pl]

I have no problem with forcing the change when the legacy is a blocker (for example I was advocating dropping TileMill support or support for osm-carto v3). What I don't like is forcing change "just in case". When we bump CartoCSS or Mapnik version dependency it means that we know the older one would not work and this is how I would like to do.

[kocio-pl]

I think it can be closed now, as #2914 is closed and the code is developed as a separate project.