PB-82: prepare migration to k8s

[ltclm]

a few changes in the dockerfile and in the efs sync script are needed during the parallel operations of service-search-sphinx on infra-vhost and k8s.

on k8s we are forced to mount the efs indexes with the full path: so this will be the folder with the efs index files:

• /var/local/geodata/service-sphinxsearch/${DBSTAGING}/index

this is due to a limitation of the aws efs csi driver which is not supporting subpaths as volumemount config. we would have to create new peristant volumes with terraform which is unreasonable for this special use-case.

[ltshb]

I don't have the full picture here, but I'm wondering if it would not be better to have a dedicated EFS Access Point for sphinx index sharing instead of reusing the /prod and /dev of our geodata EFS ? We could reuse the geodata EFS but use another access point to better separate the search index from the geodata. This would not add more cost and would be clearer in the configuration. If sphinx needs also the geodata for indexing it can still mount both the geodata /prod|/dev and the new access point /service-search-sphinx-index-dev|int|prod

[ltflb-bgdi]

As far as I can tell, looks good.

[ltclm]

I don't have the full picture here, but I'm wondering if it would not be better to have a dedicated EFS Access Point for sphinx index sharing instead of reusing the /prod and /dev of our geodata EFS ? We could reuse the geodata EFS but use another access point to better separate the search index from the geodata. This would not add more cost and would be clearer in the configuration. If sphinx needs also the geodata for indexing it can still mount both the geodata /prod|/dev and the new access point /service-search-sphinx-index-dev|int|prod

@ltshb
thats a good point, i have added it to the open questions here:
https://github.com/geoadmin/infra-kubernetes/pull/482

[rebert]

lgtm

[ltclm]

i will merge this now so that we can observe sphinx on k8s on dev under real-life conditions.