Updates to CKAN 2.11 and master images (remove supervisor and tidy up)#77
Updates to CKAN 2.11 and master images (remove supervisor and tidy up)#77
Conversation
- remove the ContainerCanary stuff - delete who.ini lines in Dockerfile - not needed anymore -
|
If supervisor gets removed, what would be the preferred way to run the harvester fetch/gather consumers? The official documentation of the extension still refers to those (see https://github.com/ckan/ckanext-harvest/blob/master/README.rst#setting-up-the-harvesters-on-a-production-server) |
|
@Markus92 - There shouldn’t be any need to run Supervisor in a Docker Compose environment. The healthcheck feature of Docker Compose does the same thing ie: process monitoring and is flexible enough to enhance something more elaborate if thats required. We are trying to avoid superfluous libraries/software in the Docker images/containers. The harvester documentation is for a standard (traditional) server based environment. I’ll create a new issue to investigate this. Are you running Harvester in its own container or is it running alongside the CKAN UI in the ckan container? |
|
@kowh-ai we're running it in the same container, set up following the manual of the harvesting extension linked above. Would we need to run separate containers? Is there any official documentation on this? We don't really care much for using the supervisor as a healthcheck, but breaking our harvesting setup would be a problem for us and require some migration path. Our internal policy is sticking as close to documented stuff as possible. Our repo is here https://github.com/GenomicDataInfrastructure/gdi-userportal-ckan-docker (forked from ckan/ckan-docker), we deploy straight to Azure app services, so no real server as to speak. |
fixes: #59
who.inilines in Dockerfile, not needed anymore as of CKAN 2.10A change to the ckan-docker repo will accompany this update. The HEALTHCHECK will be at the Docker Compose level as this has precedence over any healthchecks at the container level