Corrupted kernel Docker image issue – Where to find the source code and Dockerfiles to build locally?

Support
1

Hello, this is Raphael from DRC/Kinshasa.

I am in the process of deploying MOSIP in a testing environment (sandbox/dev) and I am encountering a blocking issue with the Docker images of the kernel (e.g., mosipid/kernel-auditmanager-service:1.2.0.1).
All the kernel pods are in CrashLoopBackOff with the following error in the logs:
java.util.zip.ZipException: zip file is empty.
Upon checking, it seems that the MOSIP Docker images for the kernel on Docker Hub are corrupted or incomplete.
I would like to build the Docker images for the kernel locally from the source code, but I cannot find a public repository containing the Java source code or the Dockerfiles for these services.

Questions:

  1. Where can I find the source code for the MOSIP kernel (and other backend modules) as well as the Dockerfiles to build the images locally?
  2. Is there official documentation or a procedure for building and publishing these images?
  3. Is it possible to obtain access (even temporary) to the source repository for sandbox/dev use?

Thank you in advance for your help!

2

Hi Raphael,

Thank you for reaching out.

To help us better understand and troubleshoot the issue, could you please share the following details:

  • Are you deploying MOSIP with DNS configuration or without DNS?
  • Which documentation are you following for the MOSIP deployment?
  • Have the Observation and MOSIP cluster components been successfully created?
  • Have the External services been deployed?
  • Before deploying the kernel services, were the Config Server and Artifactory deployed and running properly?
  • Lastly, could you let us know which Artifactory version you are using?

Once we have this information, we’ll be in a better position to assist you further.

Looking forward to your response.

Best regards,
Team MOSIP.

3

Hello MOSIP Team,

Thank you for your response. Here are the requested details about our MOSIP deployment:

1. DNS Configuration

  • Configuration: We are deploying MOSIP without DNS (development environment)
  • Setup: Using Minikube cluster with IP 192.168.49.2
  • Domain configuration: Using placeholder domains like *.sandbox.xyz.net in the global configmap
  • SSL: No valid SSL certificates (development setup)

2. Documentation Followed

  • Primary documentation: MOSIP V3 Deployment guide from the official repository
  • Repository: Using the official MOSIP Helm charts from https://mosip.github.io/mosip-helm
  • Deployment approach: Following the recommended sequence: External components → Config Server → Kernel services

3. MOSIP Cluster and Observation Module Status

  • Kubernetes cluster: Successfully created (Minikube v1.36.0 with Kubernetes v1.33.1)
  • Namespaces created: All required namespaces exist (config-server, kernel, mosip-external, etc.)
  • Observation module: Partially deployed - Istio CRDs installed manually, Prometheus Operator CRDs installation in progress

4. External Services Status

All external services successfully deployed and running:

  • PostgreSQL: mosip-postgres-postgresql-0 - Running (2d6h uptime)
  • Keycloak: mosip-keycloak-0 - Running (2d5h uptime, some restarts due to resource constraints)
  • Kafka: 3 controller pods running (2d5h uptime)
  • MinIO: mosip-minio-* pods running (2d5h uptime)
  • Helm releases: All external services show “deployed” status

5. Config Server and Artifactory Status

  • Config Server: NOT WORKING - Main issue we’re facing

    • Status: Pod stuck in CreateContainerConfigError
    • Problem: Missing keys in various secrets/configmaps (softhsm-kernel, softhsm-ida, activemq-host, etc.)
    • Helm release: Currently uninstalled due to troubleshooting

  • Artifactory: NOT DEPLOYED

    • Namespace exists but no pods deployed
    • This might be part of the issue

6. Artifactory Version

  • Status: Artifactory is not currently deployed
  • Question: Should Artifactory be deployed before Config Server? We may have missed this step.

Current Issue Summary

The main blocker is the Config Server failing to start due to missing configuration keys in secrets and configmaps. We’ve been iteratively fixing missing keys, but new ones keep appearing, suggesting we might be missing a fundamental setup step.

Questions for your team:

  1. Is Artifactory deployment mandatory before Config Server?
  2. Do you have a script or method to initialize all required secrets/configmaps at once?
  3. Should we follow a different sequence for development/non-DNS environments?

We would appreciate guidance on the correct deployment sequence and any missing prerequisites.

Best regards,
Raphaël

4

Hi @nayops

Thank you for reaching out with your questions. Please find our responses below:

  1. Is Artifactory deployment mandatory before Config Server?
    No, Artifactory deployment should follow Config Server deployment. Please refer to the deployment sequence outlined in the README of the respective repositories (links provided below).
  2. Do you have a script or method to initialize all required secrets/configmaps at once?
    There is no consolidated script at the moment. It is crucial to follow the sequence mentioned in the documentation to ensure that all required secrets and config maps are initialized correctly.
  3. Should we follow a different sequence for development/non-DNS environments?
    No, the deployment sequence remains the same across all environments. Any deviation, especially in the external modules, may result in missing secrets/config maps, which can cause issues such as CrashLoopBackOff or CreateContainerConfigError during Config Server deployment.
  4. General Guidance:

Following this order is essential for a successful and stable deployment.

Thanks and regards,
Team MOSIP

5

Hi @nayops

Just checking in - hope the issue has been resolved after following the guidance provided in our previous response.
Could you please confirm if everything is working as expected now?

Looking forward to your update.

Best regards,
Team MOSIP