Arquitectura

Una instalación de Portal Andino está formada por ocho contenedores Docker, definidos en docker-compose.yml, que se levantan juntos y se comunican por redes internas. Esta página describe la instalación de producción; las diferencias con el entorno de desarrollo se explican al final.

Diagrama general

El diagrama muestra el servidor completo: qué contenedores corren dentro, cómo se conectan entre sí y con el exterior, y en qué volumen o servicio se guarda cada parte de un dataset.

Las etiquetas violetas indican dónde se guarda cada parte de un dataset. Las flechas muestran quién inicia cada conexión, y la línea vertical agrupa las redes internas por las que ckan y ckan-worker llegan a la base de datos, a Solr y a Redis.

Contenedor por contenedor

Al elegir un contenedor, en el mosaico o en el diagrama, ese contenedor queda en color pleno, los que se comunican con él quedan en color atenuado y el resto se apaga en gris. Debajo aparece su descripción y el efecto que tiene su caída sobre el resto del portal.

»nginx∞ckan≡db≈solr+solr-init↻ckan-worker•••redis↑datapusher

• Contenedor elegido
• Se comunica con el elegido
• Sin conexión directa

nginxServidor web de entrada

Recibe todas las conexiones que llegan desde internet, se encarga del cifrado HTTPS y las reenvía a CKAN. Es el único contenedor que publica puertos en el servidor; por defecto, el 80 y el 8443.

Si se cae

El portal deja de responder desde el navegador, aunque el resto de los contenedores sigue funcionando y no se pierde ningún dato.

Se comunica con

ckan

Imagen

nginx/Dockerfile

ckanAplicación web y API del portal

Ejecuta CKAN 2.11 con todas las extensiones instaladas y atiende tanto las páginas del portal como la API. Al arrancar corre prerun.py, que espera a que la base de datos y Solr estén disponibles y crea el usuario administrador, y después los scripts de docker-entrypoint.d/.

Si se cae

nginx responde con un error 502. La causa suele aparecer en las últimas líneas de docker compose logs ckan.

Se comunica con

nginx, db, solr, redis, datapusher

Imagen

ckan/Dockerfile, sobre ckan/ckan-base:2.11

dbBase de datos PostgreSQL

Aloja dos bases: la de CKAN, donde se guardan datasets, usuarios, organizaciones y fuentes de harvesting, y la del datastore, que contiene el contenido de los archivos tabulares. Los datos persisten en el volumen pg_data.

Si se cae

CKAN no llega a arrancar, porque prerun.py queda esperando indefinidamente la conexión a la base.

Se comunica con

ckan, ckan-worker

Imagen

postgresql/Dockerfile

solrÍndice de búsqueda

El buscador del portal no consulta la base de datos sino este índice, en el que CKAN copia cada dataset al crearlo o modificarlo. Incluye además un campo espacial, spatial_geom, que permite buscar por área en el mapa.

Si se cae

Las fichas de los datasets se siguen abriendo, pero la búsqueda y los listados dejan de funcionar.

Se comunica con

ckan, ckan-worker, solr-init

Imagen

ckan/solr/Dockerfile

solr-initPreparación inicial de Solr

Se ejecuta una sola vez al levantar el stack: espera a que Solr responda, agrega el tipo de campo location_rpt y el campo spatial_geom, recarga el índice y termina. Por eso es normal que figure con estado "exited (0)".

Si se cae

La búsqueda por área en el mapa no devuelve resultados, aunque el resto del buscador funciona.

Se comunica con

solr

Imagen

curlimages/curl

ckan-workerTareas en segundo plano

Usa la misma imagen que ckan, pero en lugar de atender la web ejecuta las tareas que no dependen de una visita: supervisord mantiene activos los procesos de harvesting (gather y fetch) y cron lanza cada cinco minutos el comando que revisa si hay jobs de harvesting pendientes.

Si se cae

Los jobs de harvesting quedan en estado Running sin avanzar, mientras que el resto del portal sigue funcionando con normalidad.

Se comunica con

redis, db, solr

Imagen

ckan/Dockerfile

redisCola de trabajos

Guarda la cola de trabajos del harvester y los datos que CKAN mantiene en Redis; en el .env de ejemplo ambos usan la base 1. Las claves del harvesting se separan según ckan.site_id, de modo que dos portales podrían compartir un mismo Redis sin mezclar sus trabajos.

Si se cae

CKAN no arranca y el harvester deja de recibir trabajos.

Se comunica con

ckan, ckan-worker

Imagen

redis:6

datapusherCarga de archivos al datastore

Lee los recursos tabulares, como los CSV, y carga su contenido en el datastore para que se puedan previsualizar en el portal y consultar por API. En la configuración actual el plugin datapusher no figura en CKAN__PLUGINS, por lo que el contenedor está activo pero no recibe trabajos (a validar).

Si se cae

Las vistas de tabla de los recursos nuevos quedan vacías.

Se comunica con

ckan

Imagen

ckan/ckan-base-datapusher

Las redes dbnet, solrnet y redisnet son internas: la base, Solr y Redis no tienen salida a internet ni se pueden alcanzar desde fuera del servidor. Los archivos subidos al portal viven en el volumen ckan_storage, que comparten ckan y ckan-worker.

Qué pasa al arrancar

Cada vez que arranca el contenedor ckan, la imagen base ejecuta prerun.py, que espera a que la base de datos y Solr estén disponibles, crea las tablas y da de alta el usuario administrador definido en CKAN_SYSADMIN_*. A continuación se ejecutan, en orden, los scripts de ckan/docker-entrypoint.d/, que están escritos para que repetirlos en cada arranque no tenga efectos no deseados.

Script	Cuándo actúa	Qué hace
01_setup_datapusher.sh	datapusher en CKAN__PLUGINS	Genera un token de API para el datapusher.
02_setup_xloader.sh	xloader en CKAN__PLUGINS	Genera el token y la conexión del xloader.
03_setup_harvester.sh	ckan_harvester en CKAN__PLUGINS	Crea o actualiza las tablas del harvesting.
04_build_js_translations.sh	Siempre	Compila las traducciones de JavaScript.
05_setup_activity.sh	activity en CKAN__PLUGINS	Crea o actualiza las tablas del historial de cambios.

A validar

El script 05_setup_activity.sh todavía no está incorporado a la rama principal del repositorio del stack.

Plugins habilitados

La lista sigue el mismo orden que la variable CKAN__PLUGINS del .env, en la que envvars tiene que quedar siempre en último lugar.

• activity

  Historial de cambios de datasets y organizaciones.

  CKAN
• image_viewtext_viewdatatables_view

  Vistas previas de imágenes, texto y tablas.

  CKAN
• datastore

  Base consultable con el contenido de los recursos tabulares.

  CKAN
• spatial_metadataspatial_query

  Guarda la cobertura geográfica y habilita la búsqueda por mapa.

  ckanext-spatial 2.3.1
• resource_proxy

  Previsualiza recursos alojados en otros dominios.

  CKAN
• geo_viewgeojson_viewwmts_viewshp_view

  Vistas de mapa para GeoJSON, WMTS y Shapefile.

  ckanext-geoview
• gobar_theme

  Aplica la identidad visual según el perfil elegido (nacional, apn o subnacional) y agrega las páginas propias del portal.

  ckanext-gobar-theme
• series_explorer

  Explorador de series de tiempo.

  ckanext-series-explorer
• harvestgobar_ckan_harvesterckan_harvesterxlsx_harvester

  Incorpora datasets de otros catálogos: archivos XLSX con el formato de datos.gob.ar, portales Andino de la primera versión y portales CKAN.

  ckanext-gobar-harvest
• scheming_datasets

  Implementa el Perfil Nacional de Metadatos, es decir, define qué campos tiene un dataset y cómo se validan.

  ckanext-scheming-gobar
• dcat

  Exporta el catálogo en DCAT (RDF, JSON-LD).

  ckanext-dcat 2.4.2
• spatial_widget_ar

  Mapa de extensión espacial en la ficha del dataset, centrado en Argentina.

  ckanext-spatial-widget-ar
• hierarchy_displayhierarchy_formhierarchy_group_form

  Permite organizar las organizaciones en niveles, por ejemplo un ministerio con sus secretarías.

  ckanext-hierarchy
• googleanalytics

  Inserta el código de Google Analytics 4 o de Tag Manager para medir visitas desde el navegador, sin credenciales del lado del servidor.

  ckanext-googleanalytics
• envvars

  Traslada las variables del .env a la configuración de CKAN; por eso tiene que ser el último plugin de la lista.

  ckanext-envvars

Forks de Datos Argentina y paquetes originales

ckanext-gobar-harvest y ckanext-scheming-gobar son forks completos de ckanext-harvest y ckanext-scheming, y usan el mismo nombre de módulo, por lo que se instala solamente el fork: si también se instalara el paquete original, uno pisaría al otro. Sus plugins se registran en pyproject.toml y no en setup.py. Para confirmar que quedó instalado el fork se puede ejecutar:

docker compose exec ckan python -c "from ckanext.harvest.harvesters import GobArCKANHarvester"

Cómo se relacionan las extensiones

Las extensiones giran alrededor del Perfil Nacional de Metadatos, que define qué campos tiene cada dataset, y cada una interviene en un momento distinto del recorrido de esos datos:

1. Los harvesters convierten lo que traen de otros portales a ese perfil.
2. scheming_datasets define los campos y los valida.
3. gobar_theme los muestra y spatial_widget_ar dibuja su cobertura geográfica.
4. dcat los exporta para que otros sistemas los lean.

Por eso no conviene cambiar el esquema de metadatos en una instancia propia: los harvesters, y datos.gob.ar cuando harvestea tu portal, esperan encontrar los campos del Perfil Nacional de Metadatos. Lo que un organismo necesita adaptar (colores, logos, textos, secciones) se hace mediante variables del theme, sin tocar el esquema.

Desarrollo y producción

	Desarrollo	Producción
Archivo	docker-compose.dev.yml	docker-compose.yml
Proyecto	portal-andino-v2-dev	portal-andino-v2
Web	ckan-dev, con su puerto publicado	ckan, detrás de nginx
Extensiones	./src montado, se editan en caliente	Instaladas dentro de la imagen
Solr	Puerto 8983 publicado	Solo red interna
Atajos	bin/compose, bin/ckan, bin/reload	docker compose

El entorno de desarrollo sirve para probar la instalación en una computadora antes de ir al servidor, y los nombres de proyecto distintos evitan que los dos entornos compartan datos si están en la misma máquina.